Why you should only build what you cannot buy

Even in 2022, the biggest competitor we face when selling an application development platform is the lingering tendency for clients to build everything in-house. Despite the clear story that history tells, there is still not enough consideration given to the execution risk of building everything in-house.

The onus is on the new wave of fintech innovators to demonstrate they have used their decades of experience building capital markets systems to come up with a solution that gives acceleration but without the loss of control that everyone fears.

I’ve lost count of the number of large projects I have been involved in over my career, but I know exactly how many were resounding successes. In a recent client engagement, we enumerated the less obvious risks of large tech projects, here are the headlines:

• New low-level code is like fine wine – it takes time in production to mature, building it at the same time as a new business solution will cause huge instability.
• Capital Markets have always struggled to share software and any new build will be forced to use its share of “sacred cow – shared tech”. This can leave people on the hook to deliver, whilst feeling they have one hand tied behind their back before they really start.
• New projects mean lots of opinions and debates on approach, this wastes time and inevitably not everyone will get their way or deal with it gracefully.
• For many reasons, hitting an end-date on a project that’s inherently hard to cost is given huge importance. Inevitably the project will be saddled with technical debt incurred by the corners cut to hit the date.
• End-date pressure will be compounded because of the prevailing view that tech projects should be much cheaper than they really are. This creates a situation where the project team feel they have been given an impossible task.
• Fully resourcing the project and getting everyone trained will take time. Hiring is harder than ever, and candidates will be suspicious of what happens when the project ends, and the surge team is no longer needed.
• Most departments continue to run-the-bank while a new system gets built. This creates tension between teams and exposes dependencies on subject-matter-experts.
• Either because no-one has the full picture or developers feel discouraged from raising potential issues, projects lack the transparency that management need if they are to help.
• Any urgent feature enhancements required by the old system while the new one is being built, need to be built twice. Longer build time means even more duplicated changes or more business pressure.
• Other priorities will come up during the life of the project, silently distracting key resources and putting further pressure on the project teams who still must deliver on their original commitments.
• Most teams don’t do large build after large build. Architects and builders tend to move teams when there’s no building to be done.

So what? Always strive to buy what you can and build what you cannot. The number of viable products and vendors has increased dramatically over the last 5 years. Don’t miss out and be left competing with other firms that deliver more features faster with vastly smaller teams.

Find out more about velox and how we #buildfaster here.

#buytobuild #writingcodeishard #veloxcore